feat(routes): pass request identity, lineage, and read-only state/notices to context providers (#459) - #556

…fix framework-mode.md ordering (from #556)

… MCP negotiation test; provider-view cross-process coverage (integration) (#554)

* fix(scripts): choose the TypeScript transform flag Node actually supports (Node 26 drops --experimental-transform-types)

runScript spawned every plain .ts script under
node --experimental-transform-types. Node 26 removed the flag
(nodejs/node#61803) and rejects it as a bad option (exit code 9), so the
Verify (Node 26) leg failed on every main push.

typeScriptTransformFlags (core/runtime.ts) decides from
process.allowedNodeEnvironmentFlags: the transform flag where the binary
accepts it (Node 22, 24), nothing on Node 26, which strips types unflagged.
Unit-tested against the flag sets of each release line.

* chore: name #554 in the changeset

* fix(scripts): name --strip-types on Node 26 so an inherited NODE_OPTIONS=--no-strip-types cannot switch TypeScript loading off

Codex review on #554: with no command-line flag the child inherited the
environment's --no-strip-types and failed on every typed .ts source. The
helper now picks the first flag the binary accepts, strongest first:
--experimental-transform-types (22, 24), then --strip-types (26). Covered by
a script-dispatch test that sets the version-appropriate switch in
NODE_OPTIONS and expects the source run to succeed regardless.

* test(routes): prove the provider request view across built surfaces; fix framework-mode.md ordering (from #556)

* fix(install): apply the operator .env layer before plugin modules evaluate and below manifest env defaults (#469)

Two findings from the #538 self-review.

Precedence: a host merges the stdio server's manifest `env` block into the
child environment, so the shell could not tell a manifest default from a host
export and reserved both — manifest env beat the file, contrary to the
documented `manifest < .env < .env.local < process.env`. The emitted stdio
entry now embeds the server's normalized `env` block as build-time literals
and `applyOperatorEnv` takes it as `manifestEnv`: a present variable is
reserved only when its value differs from the embedded default, so a
passed-through default yields to the file while a host or operator export is
kept. An operator export equal to the default is indistinguishable from the
pass-through and yields too; a default carrying a path token never equals its
expanded value and is always kept. Host manifests are unchanged.

Import timing: the layer was a statement after the consumer imports, and ESM
evaluates static imports first, so module-level `process.env` reads in hook
handlers and CLI route/provider modules never saw the file. A dynamic
`import()` after the statement does not help either — Rspack inlines a
single-chunk bundle into one scope and places the dynamic target ahead of
the static imports. The layer is now a generated virtual module
(`agent-bundle/launch-env-layer`) that every stdio entry, hook wrapper, and
artifact CLI bin imports first, with the server module, handler, routes,
providers, and state definition as static imports after it; the build marks
generated modules side-effectful so a consumer `"sideEffects": false` cannot
drop the bare import. The MCP shell's `loadEntry` becomes a static import
for the same reason, so the console guard now covers the factory call and
the running server rather than the module's top-level evaluation.

Tests build each shell through the real pipeline and run it under node with
a `process.env` read at module top level: manifest-only key takes the file,
host-exported key keeps the host value, absent key takes the file,
`AGENT_BUNDLE_ENV_FILE=none` restores the previous behaviour.

* chore: drop the tracked .superpowers scratch notes and ignore the folder

* fix(mcp): install the stdout guard in the stdio entry's first import so module-scope writes never reach the protocol stream (#469)

The env-precedence follow-up made the generated stdio entry import the
server module statically so the operator .env layer lands by import order —
but that put the module's top level ahead of the console guard that
`runGeneratedStdioMcpEntry` installs in the shell body. A `console.log` or
`process.stdout.write` at module scope in a consumer's server or tool module
reached stdout, which carries JSON-RPC framing, contradicting the documented
guarantee that redirection precedes the consumer module's evaluation.

The stdio shell now imports a generated prelude (`agent-bundle/stdio-prelude`)
as its first import: it calls `redirectConsoleToStderr` from
`agent-bundle/mcp-entry`, then applies the operator .env layer with the
server's manifest env defaults. Hook wrappers and the artifact CLI bin keep
the env-only layer (`agent-bundle/launch-env-layer`) — they legitimately
write stdout. The guard has one implementation: `redirectConsoleToStderr`
returns the guard already installed (recognised by `process.stdout.write`
still being its redirect) instead of stacking a second, which would capture
the redirect as the original and restore stdout to stderr; the lifecycle
adopts the prelude's guard and restores raw stdout from it before serving.

Tests: a built stdio entry whose server module writes `console.log('hello')`
and `process.stdout.write('raw\n')` at module scope, driven by a real stdio
client through initialize, tools/list, and tools/call, asserts both land on
stderr (fails on the previous code: stderr held only the factory-time line);
the entry-shell unit tests pin the prelude as the stdio entry's first import
and the env-only layer for hook wrappers and the CLI bin; the mcp-entry unit
test pins guard adoption and re-install after restore.

* fix(mcp): adopt the installed stdout guard regardless of write identity so a consumer wrapper cannot stack a second guard (#469)

Adoption by identity (`process.stdout.write === redirectedWrite`) broke the
moment a consumer module wrapped `process.stdout.write` at module scope: the
lifecycle's `redirectConsoleToStderr()` saw a foreign function, installed a
second guard with the wrapper recorded as the original, and restoring for
the protocol stream handed stdout to the wrapper — which still forwarded to
the first redirect, so every JSON-RPC frame left on stderr and the client
hung in initialize.

The rule is now: while a guard is installed, `redirectConsoleToStderr()`
returns it whatever `process.stdout.write` has become; `restoreProtocolStdout()`
restores the real original the guard owns, writes one stderr line if a module
replaced the write in the meantime (the replacement is discarded — stdout is
the protocol channel and wrapping it is unsupported), and clears the
installed guard so a later call installs anew.

Tests: the mcp-entry unit test wraps the redirect, adopts the same guard,
restores to the real stdout, and installs fresh afterwards (fails on
a677371 at the adoption step); the packed stdio test's server module now
also wraps `process.stdout.write` at module scope and the real client still
completes initialize, tools/list, and tools/call with the wrapper's output
and the warning on stderr (hangs to timeout on a677371).

* fix(mcp): make restoreProtocolStdout once-only so a stale or repeated restore cannot clobber a fresh guard (#469)

Two holders of the same guard could restore twice: after the first restore
and a fresh install, the stale restore overwrote the fresh redirect with the
old original while `installedGuard` still named the fresh guard, so adoption
returned a guard that was no longer installed. A plain double restore also
emitted the foreign-wrapper warning twice. The guard now records that it has
restored and returns immediately on later calls.